Open
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
🦋 Changeset detectedLatest commit: 596c497 The changes in this PR will be included in the next version bump. This PR includes changesets to release 24 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughRename and reshape rev-share-limit and pie-split rule/metric/serialization fields: Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Client
participant Leaderboard as LeaderboardBuilder
participant Rules as RulesModule
participant Metrics as MetricsBuilder
participant Serializer as Serializer
Client->>Leaderboard: request leaderboard
Leaderboard->>Rules: load rules (awardPool, baseAnnualRevenueContribution, maxBaseRevenueShare)
Leaderboard->>Metrics: compute per-referrer uncappedAward using rules
Metrics->>Leaderboard: return uncappedAward
Leaderboard->>Leaderboard: cap awards (cappedAward = min(uncappedAward, awardPoolRemaining))
Leaderboard->>Serializer: serialize rules + referrer metrics (awardPool, uncappedAward, cappedAward)
Serializer->>Client: respond with serialized leaderboard
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
Greptile SummaryThis PR is a pure rename/refactoring across the
Confidence Score: 5/5Safe to merge — all renames are applied consistently with no stale references or logic changes. All 10 changed files are internally consistent with the new field names. No logic was altered — only identifier names. The sole open question is the semver bump level, which is a P2 style concern that does not block merge. Only .changeset/bright-foxes-dance.md warrants a second look regarding whether Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[ReferralEvent input] --> B[buildReferrerLeaderboardRevShareLimit]
B --> C{isReferrerQualifiedRevShareLimit}
C -->|threshold check| D[rules.minBaseRevenueContribution]
C -->|renamed from minQualifiedRevenueContribution| D
B --> E[scalePrice]
E -->|share fraction| F[rules.maxBaseRevenueShare]
F -->|renamed from qualifiedRevenueShare| F
B --> G[buildAwardedReferrerMetricsRevShareLimit]
G --> H[uncappedAwardValue\nmaxBaseRevenueShare × totalBaseRevenueContribution\nrenamed from standardAwardValue]
G --> I[cappedAwardValue\npool-capped actual award\nrenamed from awardPoolApproxValue]
G --> J[ReferrerLeaderboardRevShareLimit output]
J --> K[rules: minBaseRevenueContribution\nrules: maxBaseRevenueShare]
J --> L[referrers: uncappedAwardValue\nreferrers: cappedAwardValue]
Reviews (1): Last reviewed commit: "renamed variables" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Pull request overview
Renames rev-share-limit rule/metric field names across the v1 referrals API to better reflect meaning (per #1786).
Changes:
- Renamed RevShareLimit rule fields:
minQualifiedRevenueContribution→minBaseRevenueContribution,qualifiedRevenueShare→maxBaseRevenueShare. - Renamed RevShareLimit awarded metric fields:
standardAwardValue→uncappedAwardValue,awardPoolApproxValue→cappedAwardValue. - Updated validation, serialization/Zod schemas, tests, and README examples to use the new names.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| packages/ens-referrals/src/v1/award-models/rev-share-limit/rules.ts | Renames rule fields and updates validation/qualification logic to match. |
| packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts | Renames awarded metric fields and updates invariants/validation/builders. |
| packages/ens-referrals/src/v1/award-models/rev-share-limit/leaderboard.ts | Updates award computation to use renamed rule/metric fields. |
| packages/ens-referrals/src/v1/award-models/rev-share-limit/leaderboard.test.ts | Updates RevShareLimit leaderboard tests for renamed fields. |
| packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts | Updates RevShareLimit Zod schemas and refinements for renamed fields. |
| packages/ens-referrals/src/v1/award-models/rev-share-limit/api/serialized-types.ts | Updates serialized type names for renamed fields. |
| packages/ens-referrals/src/v1/award-models/rev-share-limit/api/serialize.ts | Updates RevShareLimit serializers to emit renamed fields. |
| packages/ens-referrals/src/v1/api/zod-schemas.test.ts | Updates v1 API schema tests to use renamed RevShareLimit fields. |
| packages/ens-referrals/README.md | Updates public docs/examples to the renamed fields. |
| .changeset/bright-foxes-dance.md | Declares a release bump for the API field renames. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts (1)
72-77:⚠️ Potential issue | 🟡 MinorReplace the stale
awardPoolShareterm in this invariant.That name is no longer exposed by this type or the rest of the renamed API, so the doc now points readers at the wrong concept.
Doc-only cleanup
- * Identifies if the referrer meets the qualifications of the {`@link` ReferralProgramRulesRevShareLimit} to receive a non-zero `awardPoolShare`. + * Identifies if the referrer meets the qualifications of the {`@link` ReferralProgramRulesRevShareLimit} to receive a non-zero award.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts` around lines 72 - 77, Update the JSDoc invariant to use the current API term instead of the stale `awardPoolShare` identifier; replace `awardPoolShare` with the renamed property `awardShare` in the comment that describes the invariant for ReferralProgramRulesRevShareLimit (the block referencing `totalBaseRevenueContribution` and `isAdminDisqualified`) so the docs point at the correct concept.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts`:
- Around line 126-137: The Zod schema must mirror
validateUnrankedReferrerMetricsRevShareLimit by rejecting any "unranked" record
whose uncappedAwardValue.amount or cappedAwardValue.amount is non-zero; update
the schema block that defines uncappedAwardValue, cappedAwardValue,
isAdminDisqualified, adminDisqualificationReason (the schema using valueLabel)
to add an additional .refine predicate that checks "if this record is unranked
(use the same unranked condition used in
validateUnrankedReferrerMetricsRevShareLimit) then uncappedAwardValue.amount ===
0 && cappedAwardValue.amount === 0", and return a clear message/path (e.g.,
path: ["uncappedAwardValue","cappedAwardValue"]) when violated so the serialized
API shape matches the runtime validator.
In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts`:
- Around line 188-210: The validator in metrics.ts enforces
cappedAwardValue.amount == 0n only for admin-disqualified referrers but misses
the contract that when metrics.isQualified === false (below-threshold)
cappedAwardValue must also be zero; update the validation logic after the
makePriceUsdcSchema parses to add a check for metrics.isQualified === false that
throws a descriptive Error if metrics.cappedAwardValue.amount !== 0n (similar to
the existing isAdminDisqualified check), referencing the same properties
(metrics.isQualified, metrics.cappedAwardValue.amount) and keeping the other
comparisons against rules.totalAwardPoolValue.amount and
metrics.uncappedAwardValue.amount intact.
---
Outside diff comments:
In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts`:
- Around line 72-77: Update the JSDoc invariant to use the current API term
instead of the stale `awardPoolShare` identifier; replace `awardPoolShare` with
the renamed property `awardShare` in the comment that describes the invariant
for ReferralProgramRulesRevShareLimit (the block referencing
`totalBaseRevenueContribution` and `isAdminDisqualified`) so the docs point at
the correct concept.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 8b1dd26f-f231-448b-a5c1-88e14a85bd69
📒 Files selected for processing (10)
.changeset/bright-foxes-dance.mdpackages/ens-referrals/README.mdpackages/ens-referrals/src/v1/api/zod-schemas.test.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/api/serialize.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/api/serialized-types.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/leaderboard.test.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/leaderboard.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/rules.ts
packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts
Outdated
Show resolved
Hide resolved
packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts
Outdated
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts
Outdated
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts`:
- Around line 139-145: The current .refine call incorrectly sets path to
["uncappedAwardValue","cappedAwardValue"] (which points to a nested path);
replace the .refine with .superRefine on the same Zod schema and, inside the
callback, check the same condition and call ctx.addIssue separately for each
offending sibling field (use paths ["uncappedAwardValue"] and
["cappedAwardValue"] respectively) with the appropriate message; use
ZodIssueCode.custom for the issues so each field gets its own validation error
instead of a nonexistent nested path.
In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts`:
- Around line 189-195: The current validator for
AwardedReferrerMetricsRevShareLimit.uncappedAwardValue only parses a PriceUsdc
but should enforce the documented invariant; compute expectedUncapped =
rules.maxBaseRevenueShare × metrics.totalBaseRevenueContribution inside the
validation logic (using the same numeric types/scale as makePriceUsdcSchema
expects) and either assert parsed uncappedAwardValue equals expectedUncapped or,
better, derive and set uncappedAwardValue from that computation instead of
trusting caller input; update
makePriceUsdcSchema("AwardedReferrerMetricsRevShareLimit.cappedAwardValue")
usage to still validate cappedAwardValue <= expectedUncapped and adjust
buildAwardedReferrerMetricsRevShareLimit() to derive uncappedAwardValue from
rules.maxBaseRevenueShare and metrics.totalBaseRevenueContribution.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 46afcbc6-f698-4608-9a08-24db3381105a
📒 Files selected for processing (2)
packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts
packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts
Outdated
Show resolved
Hide resolved
packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts
Outdated
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts (1)
120-146:⚠️ Potential issue | 🟠 MajorMirror the rest of the unranked zero-metric contract in this schema.
validateUnrankedReferrerMetricsRevShareLimit()still rejects non-zerototalReferrals,totalIncrementalDuration,totalRevenueContribution.amount, andtotalBaseRevenueContribution.amount, but this schema only encodes the zero-award checks. That leaves the serialized API shape looser than the runtime model and allows invalid unranked payloads to parse here.Suggested schema tightening
.object({ referrer: makeLowercaseAddressSchema(`${valueLabel}.referrer`), totalReferrals: makeNonNegativeIntegerSchema(`${valueLabel}.totalReferrals`), totalIncrementalDuration: makeDurationSchema(`${valueLabel}.totalIncrementalDuration`), totalRevenueContribution: makePriceEthSchema(`${valueLabel}.totalRevenueContribution`), totalBaseRevenueContribution: makePriceUsdcSchema( `${valueLabel}.totalBaseRevenueContribution`, ), rank: z.null(), isQualified: z.literal(false), uncappedAwardValue: makePriceUsdcSchema(`${valueLabel}.uncappedAwardValue`), cappedAwardValue: makePriceUsdcSchema(`${valueLabel}.cappedAwardValue`), isAdminDisqualified: z.boolean(), adminDisqualificationReason: z .string() .trim() .min(1, `${valueLabel}.adminDisqualificationReason must not be empty`) .nullable(), }) + .refine((data) => data.totalReferrals === 0, { + message: `${valueLabel}.totalReferrals must be 0 for unranked referrers`, + path: ["totalReferrals"], + }) + .refine((data) => data.totalIncrementalDuration === 0, { + message: `${valueLabel}.totalIncrementalDuration must be 0 for unranked referrers`, + path: ["totalIncrementalDuration"], + }) + .refine((data) => data.totalRevenueContribution.amount === 0n, { + message: `${valueLabel}.totalRevenueContribution must be 0 for unranked referrers`, + path: ["totalRevenueContribution"], + }) + .refine((data) => data.totalBaseRevenueContribution.amount === 0n, { + message: `${valueLabel}.totalBaseRevenueContribution must be 0 for unranked referrers`, + path: ["totalBaseRevenueContribution"], + }) .refine((data) => data.uncappedAwardValue.amount === 0n, {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts` around lines 120 - 146, The schema for unranked referrers currently only enforces zero award values but must also mirror the runtime validator validateUnrankedReferrerMetricsRevShareLimit: add checks to the zod object (around the same chain where rank is z.null() and isQualified is z.literal(false)) to require totalReferrals === 0, totalIncrementalDuration === 0 (or duration.amount === 0 depending on the duration shape), totalRevenueContribution.amount === 0n, and totalBaseRevenueContribution.amount === 0n; implement these as additional .refine() calls (or a single .superRefine()) referencing the fields totalReferrals, totalIncrementalDuration, totalRevenueContribution, and totalBaseRevenueContribution so the parsed API shape matches the runtime validation.
♻️ Duplicate comments (1)
packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts (1)
189-195:⚠️ Potential issue | 🟠 MajorDon't accept an arbitrary
uncappedAwardValuehere.This field is documented as
rules.maxBaseRevenueShare × totalBaseRevenueContribution, but the validator only parses it as a genericPriceUsdcand the builder still takes it from callers. Any inflateduncappedAwardValuecurrently passes as long ascappedAwardValue <= uncappedAwardValue, which weakens the renamed contract. Recompute the expected uncapped amount fromrules.maxBaseRevenueShareandtotalBaseRevenueContributionhere, or derive it insidebuildAwardedReferrerMetricsRevShareLimit()instead of accepting it as input. Based on learnings: Inpackages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts,AwardedReferrerMetricsRevShareLimit.standardAwardValueshould not duplicate the genericPriceUsdcnon-negative invariant; keep only the context-specific formula (“rules.qualifiedRevenueShare × totalBaseRevenueContribution”) and notes about pool independence.Also applies to: 222-231
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts` around lines 189 - 195, The code currently accepts an arbitrary uncappedAwardValue and only validates it as a generic PriceUsdc; instead recompute and validate uncappedAwardValue from the formula rules.maxBaseRevenueShare × totalBaseRevenueContribution (or move that derivation into buildAwardedReferrerMetricsRevShareLimit()) and validate the computed value against cappedAwardValue, rather than trusting caller input for AwardedReferrerMetricsRevShareLimit.uncappedAwardValue; likewise remove the redundant generic non-negative PriceUsdc check for AwardedReferrerMetricsRevShareLimit.standardAwardValue and keep only the context-specific invariant/description that it equals rules.qualifiedRevenueShare × totalBaseRevenueContribution and is pool-independent. Ensure references to makePriceUsdcSchema, cappedAwardValue, standardAwardValue, buildAwardedReferrerMetricsRevShareLimit, rules.maxBaseRevenueShare, rules.qualifiedRevenueShare, and totalBaseRevenueContribution are used to locate and update the logic.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In
`@packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts`:
- Around line 120-146: The schema for unranked referrers currently only enforces
zero award values but must also mirror the runtime validator
validateUnrankedReferrerMetricsRevShareLimit: add checks to the zod object
(around the same chain where rank is z.null() and isQualified is
z.literal(false)) to require totalReferrals === 0, totalIncrementalDuration ===
0 (or duration.amount === 0 depending on the duration shape),
totalRevenueContribution.amount === 0n, and totalBaseRevenueContribution.amount
=== 0n; implement these as additional .refine() calls (or a single
.superRefine()) referencing the fields totalReferrals, totalIncrementalDuration,
totalRevenueContribution, and totalBaseRevenueContribution so the parsed API
shape matches the runtime validation.
---
Duplicate comments:
In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts`:
- Around line 189-195: The code currently accepts an arbitrary
uncappedAwardValue and only validates it as a generic PriceUsdc; instead
recompute and validate uncappedAwardValue from the formula
rules.maxBaseRevenueShare × totalBaseRevenueContribution (or move that
derivation into buildAwardedReferrerMetricsRevShareLimit()) and validate the
computed value against cappedAwardValue, rather than trusting caller input for
AwardedReferrerMetricsRevShareLimit.uncappedAwardValue; likewise remove the
redundant generic non-negative PriceUsdc check for
AwardedReferrerMetricsRevShareLimit.standardAwardValue and keep only the
context-specific invariant/description that it equals
rules.qualifiedRevenueShare × totalBaseRevenueContribution and is
pool-independent. Ensure references to makePriceUsdcSchema, cappedAwardValue,
standardAwardValue, buildAwardedReferrerMetricsRevShareLimit,
rules.maxBaseRevenueShare, rules.qualifiedRevenueShare, and
totalBaseRevenueContribution are used to locate and update the logic.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0e0628e2-9060-4a54-a071-462eaecf1002
📒 Files selected for processing (2)
packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts
Contributor
|
Caution Failed to replace (edit) comment. This is likely due to insufficient permissions or the comment being deleted. Error details |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts (1)
191-209:⚠️ Potential issue | 🟠 MajorMirror the award-pool ceiling in the composite schemas.
validateAwardedReferrerMetricsRevShareLimit()rejectscappedAwardValue.amount > rules.awardPool.amount, but these parent schemas still accept those payloads because the child schema cannot seerules. That leaves the serialized API surface looser than the runtime model.Suggested fix
export const makeReferrerEditionMetricsRankedRevShareLimitSchema = ( valueLabel: string = "ReferrerEditionMetricsRankedRevShareLimit", ) => z .object({ awardModel: z.literal(ReferralProgramAwardModels.RevShareLimit), type: z.literal(ReferrerEditionMetricsTypeIds.Ranked), rules: makeReferralProgramRulesRevShareLimitSchema(`${valueLabel}.rules`), referrer: makeAwardedReferrerMetricsRevShareLimitSchema(`${valueLabel}.referrer`), aggregatedMetrics: makeAggregatedReferrerMetricsRevShareLimitSchema( `${valueLabel}.aggregatedMetrics`, ), status: makeReferralProgramStatusSchema(`${valueLabel}.status`), accurateAsOf: makeUnixTimestampSchema(`${valueLabel}.accurateAsOf`), }) + .refine((data) => data.referrer.cappedAwardValue.amount <= data.rules.awardPool.amount, { + message: `${valueLabel}.referrer.cappedAwardValue must be <= ${valueLabel}.rules.awardPool`, + path: ["referrer", "cappedAwardValue"], + }) .refine((data) => data.awardModel === data.rules.awardModel, { message: `${valueLabel}.awardModel must equal ${valueLabel}.rules.awardModel`, path: ["awardModel"], }); export const makeReferrerLeaderboardPageRevShareLimitSchema = ( valueLabel: string = "ReferrerLeaderboardPageRevShareLimit", ) => makeBaseReferrerLeaderboardPageSchema(valueLabel) .safeExtend({ awardModel: z.literal(ReferralProgramAwardModels.RevShareLimit), rules: makeReferralProgramRulesRevShareLimitSchema(`${valueLabel}.rules`), referrers: z.array( makeAwardedReferrerMetricsRevShareLimitSchema(`${valueLabel}.referrers[record]`), ), aggregatedMetrics: makeAggregatedReferrerMetricsRevShareLimitSchema( `${valueLabel}.aggregatedMetrics`, ), }) + .superRefine((data, ctx) => { + data.referrers.forEach((referrer, index) => { + if (referrer.cappedAwardValue.amount > data.rules.awardPool.amount) { + ctx.addIssue({ + code: z.ZodIssueCode.custom, + message: `${valueLabel}.referrers[${index}].cappedAwardValue must be <= ${valueLabel}.rules.awardPool`, + path: ["referrers", index, "cappedAwardValue"], + }); + } + }); + }) .refine((data) => data.awardModel === data.rules.awardModel, { message: `${valueLabel}.awardModel must equal ${valueLabel}.rules.awardModel`, path: ["awardModel"], });Also applies to: 266-283
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts` around lines 191 - 209, The composite schema makeReferrerEditionMetricsRankedRevShareLimitSchema currently only checks awardModel equality but must also enforce the award-pool ceiling: add a .refine that compares data.referrer.cappedAwardValue.amount (when present) against data.rules.awardPool.amount and fails if cappedAwardValue.amount > rules.awardPool.amount, returning a clear message/path (e.g., path ["referrer","cappedAwardValue","amount"]). Apply the same additional refine to the corresponding composite schema(s) mentioned (the one at lines 266-283) so child validation that depends on rules.awardPool is enforced at the parent level as well.
♻️ Duplicate comments (1)
packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts (1)
160-166:⚠️ Potential issue | 🟠 MajorDerive
uncappedAwardValueinstead of accepting it as input.This field is documented as
maxBaseRevenueShare × totalBaseRevenueContribution, butvalidateAwardedReferrerMetricsRevShareLimit()only parses a genericPriceUsdcandbuildAwardedReferrerMetricsRevShareLimit()still trusts the caller. That lets internally inconsistent awarded rows pass as long ascappedAwardValue.amount <= uncappedAwardValue.amount. Please compute it fromrules.maxBaseRevenueSharein the builder, or at least recompute and compare it during validation.Also applies to: 188-190, 221-233
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts` around lines 160 - 166, The uncappedAwardValue field is being accepted from input instead of being derived, allowing inconsistent rows; update buildAwardedReferrerMetricsRevShareLimit to compute uncappedAwardValue as rules.maxBaseRevenueShare × totalBaseRevenueContribution (use the same PriceUsdc math used elsewhere) and remove/ignore any incoming uncappedAwardValue, and update validateAwardedReferrerMetricsRevShareLimit to recompute uncappedAwardValue from rules.maxBaseRevenueShare and compare it against the provided cappedAwardValue (and fail if cappedAwardValue.amount > derived uncappedAwardValue.amount); apply the same change to the other affected spots referenced around lines 188-190 and 221-233 so uncappedAwardValue is always derived from rules.maxBaseRevenueShare and totalBaseRevenueContribution rather than trusted from input.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts`:
- Around line 71-76: The doc comment for the eligibility predicate incorrectly
states a non-zero payout; update the summary and invariant for the
function/field that references ReferralProgramRulesRevShareLimit so it describes
rule-based eligibility only (i.e., that totalBaseRevenueContribution >=
minBaseRevenueContribution and isAdminDisqualified is false) and explicitly omit
any guarantee about cappedAwardValue.amount being non-zero (since the pool may
be exhausted). Ensure the wording mentions eligibility under the rules rather
than a guaranteed non-zero payout and keep references to
totalBaseRevenueContribution,
ReferralProgramRulesRevShareLimit.minBaseRevenueContribution,
isAdminDisqualified, and cappedAwardValue.amount so maintainers can locate the
related logic.
---
Outside diff comments:
In
`@packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts`:
- Around line 191-209: The composite schema
makeReferrerEditionMetricsRankedRevShareLimitSchema currently only checks
awardModel equality but must also enforce the award-pool ceiling: add a .refine
that compares data.referrer.cappedAwardValue.amount (when present) against
data.rules.awardPool.amount and fails if cappedAwardValue.amount >
rules.awardPool.amount, returning a clear message/path (e.g., path
["referrer","cappedAwardValue","amount"]). Apply the same additional refine to
the corresponding composite schema(s) mentioned (the one at lines 266-283) so
child validation that depends on rules.awardPool is enforced at the parent level
as well.
---
Duplicate comments:
In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts`:
- Around line 160-166: The uncappedAwardValue field is being accepted from input
instead of being derived, allowing inconsistent rows; update
buildAwardedReferrerMetricsRevShareLimit to compute uncappedAwardValue as
rules.maxBaseRevenueShare × totalBaseRevenueContribution (use the same PriceUsdc
math used elsewhere) and remove/ignore any incoming uncappedAwardValue, and
update validateAwardedReferrerMetricsRevShareLimit to recompute
uncappedAwardValue from rules.maxBaseRevenueShare and compare it against the
provided cappedAwardValue (and fail if cappedAwardValue.amount > derived
uncappedAwardValue.amount); apply the same change to the other affected spots
referenced around lines 188-190 and 221-233 so uncappedAwardValue is always
derived from rules.maxBaseRevenueShare and totalBaseRevenueContribution rather
than trusted from input.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 4650b688-71a2-4791-8f22-23be55aaa5d7
📒 Files selected for processing (19)
.changeset/bright-foxes-dance.mdapps/ensapi/src/lib/ensanalytics/referrer-leaderboard/mocks-v1.tspackages/ens-referrals/README.mdpackages/ens-referrals/src/v1/api/zod-schemas.test.tspackages/ens-referrals/src/v1/award-models/pie-split/api/serialize.tspackages/ens-referrals/src/v1/award-models/pie-split/api/serialized-types.tspackages/ens-referrals/src/v1/award-models/pie-split/api/zod-schemas.tspackages/ens-referrals/src/v1/award-models/pie-split/metrics.tspackages/ens-referrals/src/v1/award-models/pie-split/rules.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/api/serialize.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/api/serialized-types.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/edition-metrics.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/leaderboard.test.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/leaderboard.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/rules.tspackages/ens-referrals/src/v1/edition-defaults.tspackages/ens-referrals/src/v1/leaderboard-page.test.ts
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 19 out of 19 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts (1)
192-198:⚠️ Potential issue | 🟠 MajorDerive
uncappedAwardValuefrom the rules instead of trusting caller input.Line 192 only validates
uncappedAwardValueas a genericPriceUsdc, and Line 227 still lets callers pass any value. That breaks the documentedmaxBaseRevenueShare × totalBaseRevenueContributioninvariant and can incorrectly widen or shrink the ceiling enforced bycappedAwardValue <= uncappedAwardValue. Since breaking changes are still acceptable in this package, I’d removeuncappedAwardValuefrom the builder input and recompute/validate it fromrules.maxBaseRevenueShareandreferrer.totalBaseRevenueContribution.Based on learnings:
AwardedReferrerMetricsRevShareLimit.standardAwardValue should not duplicate the generic PriceUsdc non-negative invariant; keep only the context-specific formula ("rules.qualifiedRevenueShare × totalBaseRevenueContribution") and notes about pool independence.Also applies to: 225-235
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts` around lines 192 - 198, Remove uncappedAwardValue from the AwardedReferrerMetricsRevShareLimit builder input and stop trusting caller-provided values; instead compute uncappedAwardValue as rules.maxBaseRevenueShare × referrer.totalBaseRevenueContribution inside the builder/constructor, then validate that computed value with makePriceUsdcSchema before using it to enforce cappedAwardValue <= uncappedAwardValue. Update any code paths that currently parse/validate incoming uncappedAwardValue (lines referencing AwardedReferrerMetricsRevShareLimit.uncappedAwardValue) to use the recomputed value, and remove the redundant non-negative check on standardAwardValue so it only documents/validates the context-specific formula (rules.qualifiedRevenueShare × totalBaseRevenueContribution).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts`:
- Around line 192-198: Remove uncappedAwardValue from the
AwardedReferrerMetricsRevShareLimit builder input and stop trusting
caller-provided values; instead compute uncappedAwardValue as
rules.maxBaseRevenueShare × referrer.totalBaseRevenueContribution inside the
builder/constructor, then validate that computed value with makePriceUsdcSchema
before using it to enforce cappedAwardValue <= uncappedAwardValue. Update any
code paths that currently parse/validate incoming uncappedAwardValue (lines
referencing AwardedReferrerMetricsRevShareLimit.uncappedAwardValue) to use the
recomputed value, and remove the redundant non-negative check on
standardAwardValue so it only documents/validates the context-specific formula
(rules.qualifiedRevenueShare × totalBaseRevenueContribution).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 48316956-f5a9-4f03-9614-63639bda3bd7
📒 Files selected for processing (2)
packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts`:
- Around line 286-293: Replace the current .refine(...) call with
.superRefine(...) on the schema and, inside the callback, iterate over
data.referrers with their index and for each referrer whose cappedAward.amount >
data.rules.awardPool.amount call ctx.addIssue with code: z.ZodIssueCode.custom
(or use ctx.addIssue({ message: ..., path: [...] })) and set the path to
["referrers", index, "cappedAward", "amount"] so the error points to the exact
referrer; use the same message template
`${valueLabel}.referrers[${index}].cappedAward must be <=
${valueLabel}.rules.awardPool` referencing data.rules.awardPool.amount and
ensure you import/use z from zod in the same module (replace the existing refine
on that schema with this superRefine logic).
In `@packages/ens-referrals/src/v1/award-models/rev-share-limit/leaderboard.ts`:
- Around line 154-164: The current already-qualified branch computes each
event's claim from the event delta (incrementalBaseRevenueAmount ->
incrementalUncappedAward via priceUsdc and scalePrice) which reintroduces
rounding on every event; instead compute the new cumulative uncapped award,
subtract the previously processed cumulative uncapped award, and claim that
difference so rounding happens only once per cumulative total. Concretely:
derive a cumulativeUncappedTotal using priceUsdc and scalePrice against the
cumulative baseAnnualRevenueContribution (or cumulative duration) and
rules.maxBaseRevenueShare, compute deltaUncapped = cumulativeUncappedTotal -
state.previousUncappedTotal, then cap that delta against poolRemainingAmount,
add to state.cappedAwardAmount, decrement poolRemainingAmount, and update
state.previousUncappedTotal; also add a regression test that sends many small
incremental events verifying the final cappedAward equals the uncapped total
when pool is not exhausted.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 483c859c-3019-451b-b54f-808dcc59664f
📒 Files selected for processing (11)
.changeset/bright-foxes-dance.mdpackages/ens-referrals/README.mdpackages/ens-referrals/src/v1/api/zod-schemas.test.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/aggregations.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/api/serialize.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/api/serialized-types.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/edition-metrics.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/leaderboard.test.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/leaderboard.tspackages/ens-referrals/src/v1/award-models/rev-share-limit/metrics.ts
packages/ens-referrals/src/v1/award-models/rev-share-limit/api/zod-schemas.ts
Outdated
Show resolved
Hide resolved
packages/ens-referrals/src/v1/award-models/rev-share-limit/leaderboard.ts
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 20 out of 20 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
lightwalker-eth
approved these changes
Apr 8, 2026
Member
lightwalker-eth
left a comment
lightwalker-eth
left a comment
There was a problem hiding this comment.
@Goader Hey nice updates 👍 Reviewed and shared a few more small suggestions. Please take the lead to merge this when ready.
| /** | ||
| * The referrer's base revenue contribution (base-fee-only: $5 × years of incremental duration). | ||
| * The referrer's base revenue contribution | ||
| * (base-fee-only: `rules.baseAnnualRevenueContribution` × years of incremental duration). |
Member
There was a problem hiding this comment.
Suggested change
| * (base-fee-only: `rules.baseAnnualRevenueContribution` × years of incremental duration). | |
| * (`rules.baseAnnualRevenueContribution` × years of incremental duration). |
| * | ||
| * Note: this is a purely rule-based eligibility predicate and does NOT guarantee | ||
| * `cappedAward.amount > 0n` — a qualified referrer may still receive $0 if the | ||
| * award pool is already depleted by earlier referrers in the race. |
Member
There was a problem hiding this comment.
Suggested change
| * award pool is already depleted by earlier referrers in the race. | |
| * capped award pool is already exhausted by earlier referrers in the race. |
| * The uncapped USDC award for this referrer, computed as | ||
| * `maxBaseRevenueShare × totalBaseRevenueContribution`. | ||
| * | ||
| * Represents what the referrer would receive if the pool were unlimited and the referrer were qualified. |
Member
There was a problem hiding this comment.
Suggested change
| * Represents what the referrer would receive if the pool were unlimited and the referrer were qualified. | |
| * Represents what the referrer would receive if the pool were uncapped and the referrer were qualified. |
| * The approximate USDC value of the referrer's award. | ||
| * The referrer's (tentative) capped USDC award. | ||
| * | ||
| * This is the amount actually claimed from the pool by this referrer, capped by |
Member
There was a problem hiding this comment.
Suggested change
| * This is the amount actually claimed from the pool by this referrer, capped by | |
| * This is the amount (tentatively) claimed from the award pool by this referrer, capped by |
| * | ||
| * This is the amount actually claimed from the pool by this referrer, capped by | ||
| * the remaining pool at the time of their qualifying events. | ||
| * the remaining pool at the time of their qualifying referrals. |
Member
There was a problem hiding this comment.
Suggested change
| * the remaining pool at the time of their qualifying referrals. | |
| * the remaining award pool at the time of their qualifying referrals. |
| * Events are processed in chronological order. When a referrer first crosses the qualification | ||
| * threshold, they claim ALL accumulated standard award value at once (capped by remaining pool). | ||
| * After qualifying, each subsequent event claims that event's incremental standard award (also | ||
| * threshold, they claim ALL accumulated uncapped award at once (capped by remaining pool). |
Member
There was a problem hiding this comment.
Suggested change
| * threshold, they claim ALL accumulated uncapped award at once (capped by remaining pool). | |
| * threshold, they claim ALL accumulated uncapped awards at once (capped by remaining award pool). |
Comment on lines
+90
to
91
| * After qualifying, each subsequent event claims that event's incremental uncapped award (also | ||
| * capped). Once the pool reaches $0, no further awards are issued to anyone. |
Member
There was a problem hiding this comment.
Suggested change
| * After qualifying, each subsequent event claims that event's incremental uncapped award (also | |
| * capped). Once the pool reaches $0, no further awards are issued to anyone. | |
| * After qualifying, each referrer's subsequent referrals claim that event's incremental capped award. | |
| * Once the award pool is exhausted, no further awards are issued to anyone. |
| * After qualifying, each subsequent event claims that event's incremental uncapped award (also | ||
| * capped). Once the pool reaches $0, no further awards are issued to anyone. | ||
| * | ||
| * @param events - Raw referral events from the database (unsorted; will be sorted internally). |
Member
There was a problem hiding this comment.
Suggested change
| * @param events - Raw referral events from the database (unsorted; will be sorted internally). | |
| * @param events - Raw referral events from ENSDb (unsorted; will be sorted internally). |
| @@ -213,23 +205,23 @@ export const buildReferrerLeaderboardRevShareLimit = ( | |||
| priceEth(state.totalRevenueContributionAmount), | |||
Member
There was a problem hiding this comment.
A few lines above this comment I see "... as ReferrerRaceState". I believe that could be replaced with a !
| // 3. referrer address desc — deterministic tie-break | ||
| // Both `a` and `b` are keys from `referrerStates`, so lookups are always defined. | ||
| const sortedAddresses = [...referrerStates.keys()].sort((a, b) => { | ||
| const stateA = referrerStates.get(a) as ReferrerRaceState; |
Member
There was a problem hiding this comment.
Please see other comment suggesting use of !
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refined
rev-share-limitvariable namescloses: #1786
Summary
rev-share-limitvariable names #1786Why
Testing
Pre-Review Checklist (Blocking)